Co-simulation refers to partitioning an electronic circuit design into multiple portions and executing simulation models of those portions on different co-simulation platforms. The co-simulation platforms may be a combination of software-based and hardware-based co-simulation platforms.
In a software-based co-simulation platform, a portion of the design is modeled and simulated with software running on a workstation, for example. In a hardware-based co-simulation platform, a portion of the design is emulated on a hardware platform that includes a programmable logic device (PLD), such as a field programmable gate array (FPGA), where the emulated portion of the design is implemented as a circuit on the PLD.
The hardware-based co-simulation platform operates under the control of the software-based co-simulation platform which coordinates communication and data transfers between the parts of the design on the hardware-based co-simulation platform and the parts of the design on the software-based co-simulation platform. Co-simulation using a hardware-based co-simulation platform may reduce the time required for a simulation run, provide hardware debugging capabilities, along with real-time verification capabilities. The Modelsim simulator and the NC-SIM simulator from Cadence are examples of software-based co-simulation platforms, and the Wildcard development platform from Annapolis Microsystems and the Benone development platform from Nallatech are examples of hardware-based co-simulation platforms. The WildCard and Benone platforms are often used for algorithm exploration and design prototyping.
In typical hardware-based co-simulation platforms, a hardware co-simulation interface (HWCIF) is combined with the portion of the design to be emulated on the hardware (design under test or “DUT”). The HWCIF is a circuit that supports interactions between the software-based co-simulation platform and the DUT. The DUT is interfaced with the HWCIF via memory mapped registers that are associated with the input/output ports of the DUT. Data is pushed into an input port of the DUT by the software-based co-simulation platform performing a memory write to the address which is mapped to one of the registers. Similarly, data is retrieved from an output port through the software-based co-simulation platform performing a memory read. The software-based co-simulation platform issues read/write operations by sending commands to the HWCIF over a communication interface. The HWCIF may be implemented with a command processor that translates commands into operations suitable for the DUT. To facilitate lock-step simulations, the HWCIF also controls clocking of the DUT. The DUT clock is temporarily gated off during the transmission of stimuli and results. After a transmission is complete, one or multiple clock cycle pulses may be applied to the DUT as controlled by the software-based co-simulation platform.
Most design tools recognize and support a hierarchical specification of the design, which allows the design to be specified and viewed at different levels of abstraction. In graphical user interface (GUI) tools the term “block” is sometimes used to refer to a collection of parts of a design that perform a function. In other tools, the term “module” is used to refer to collection of parts of a design that perform a function. Each block or module has a defined set of input and output ports that are connected to other blocks or modules of the design.
Hardware co-simulation helps accelerate simulation of the design, and a designer would typically desire co-simulating in hardware those modules of the design that have been sufficiently developed and tested. As development and testing of the overall design proceeds, the designer may desire to co-simulate in hardware additional modules of the design. Also, in some scenarios a designer may desire to switch between co-simulating a module in hardware or software of different simulation runs.
The present invention may address one or more of the above issues.